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SUMMARY 


The results of the aircraft design process are best given in graphical, pictorial, and tabular form. 
The computer-based aircraft synthesis programs currently being developed will generate this graph- 
ical output. The Advanced Vehicle Concepts Branch, NASA-Ames, has been implementing an 
aircraft synthesis program with computer graphics since 1971. This paper describes the history of 
the program development and compares a system based on time-sharing to two different concepts 
based on distributed computing. 


INTRODUCTION 


Increasing automation in the airplane design process is an important subject of research within 
the government and aviation industry (refs. 1-11). The implementation of such plans will call for 
eventual widespread use of computer-generated graphical output. The purpose of this paper is to 
relate the experience of the Advanced Vehicle Concepts Branch, NASA Ames Research Center, in 
implementing computer-generated graphics in conjunction with the program for aircraft synthesis 
(ACSYNT). 


AIRCRAFT SYNTHESIS 


There is a substantial effort in the aeronautical research community to develop a computer- 
based procedure for the synthesis of aircraft configurations (refs. 1-8). The first task in this research 
effort is to identify and model all first-order effects on aircraft configuration definition. These 
mathematical models are coded into procedures in the various technical disciplines, such as aero- 
dynamics or propulsion, and coupled through a common data base. By appropriate control logic, an 
aircraft configuration is synthesized that satisfies the desired mission objectives. This computerized, 
preliminary design process can provide important information that can influence the direction and 
magnitude of the overall airplane project at considerably less cost in time and money than a 
traditional preliminary design. 

At the Ames Research Center, the Advanced Vehicle Concepts Branch uses such a synthesis 
program (ACSYNT) for conceptual design studies of proposed aircraft. The function of an aircraft 
design capability within NASA is to define quantitative measures of the performance of 
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aeronautical concepts. This permits judgments to be made on the value of various research projects 
competing for the limited resources available and provides information for the direction and sup- 
port of NASA aeronautical research. 


GRAPHICS IN AIRCRAFT SYNTHESIS 


Since the results of a traditional design study are presented in the form of charts, graphs, 
drawings, etc., the computer-based study should yield these same results (figs. 1-1 2). The process of 
generating this graphical data can be very demanding of engineering time. In view of the capabilities 
of modem computer graphics hardware, the most rapid and accurate way to produce such graphical 
output is to include it in the computer synthesis program. 

A fundamental guideline, established early in the development of ACSYNT, is that inter- 
mediate and final results should be displayed or plotted in graphical form. A second guideline is that 
the quality of figures be sufficiently high to allow their use in reports without retouching or 
redrawing. The selection of graphics hardware has been guided by the requirements that graphics be 
available quickly and that permanent copies be obtainable. 


ACSYNT PROGRAM STRUCTURE 


The program structure is illustrated in figure 13. Since one of the ACSYNT guidelines is to 
avoid machine dependence, the picture creation commands are not directly contained in the 
discipline-oriented modules. Instead, each module produces an external file containing all the data 
necessary to create the desired pictures. Upon convergence of the design algorithm, the various files 
are merged into one combined file of results which is then cataloged and is available for presenta- 
tion to the user. This is a numerical file and not a graphics file at this point. The graphics post- 
processor routines are invoked to create and format the plot file of graphical information. This file 
is written in a specially coded form that can be translated into pictures by any of several devices. 

This structure has remained relatively constant over the past few years although the methods 
for implementing the actual transmission and display of the pictures to the user have undergone 
several major modifications to adapt to the changing computing environment. The modularization 
of the program has been very valuable in enabling the adaptation. 


HISTORY OF SYSTEM DEVELOPMENT 


The implementation of graphical display for ACSYNT was based on the following assump- 
tions; 

1 . The user wishes to see the results as quickly as possible after initiation of the job. 

2. The user wishes to maintain a certain amount of interactive control over what displays are 
shown. 
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3. The user wishes to obtain permanent copies of the graphics and charts but is willing to wait 
1-2 days for these if the CRT-type display is available and recallable. 

The original implementation utilized a CRT-display computer (an IMLAC PDS-1 ) as a terminal 
to a time-shared host computer (an IBM 360/67) (fig. 1 4). The ACSYNT program was executed on 
the 360 and created the data file in the central on-line storage of the 360. The displays were 
generated by a program that was executed in the 360 utilizing a graphics language that could drive 
both the IMLAC display and the microfilm plotter (an SC4020) to satisfy the requirement for 
hardcopy. The coding of the display program allowed the user to inspect each plot and then 
proceed to the next one. 

This system was implemented, but the total workload on the time-shared host computer was 
sufficiently heavy that the action seen by the user was very slow and unresponsive. When optimiza- 
tion of the code and operational procedures did not alleviate the problem, it was decided to 
abandon the concept of interactive graphics for ACSYNT until sufficient resources could be guaran- 
teed on a time-sharing system. 

In foregoing interactive operation of the program, the problem of presenting graphical output 
was reexamined. The original implementation allowed plots to be made on the microfilm plotter, 
but the time delay in obtaining the prints was excessive. An alternate approach was devised that 
enabled the time-sharing computer to generate a picture file that was sent to a graphics support 
computer (an IBM 1800). This graphics support computer operates a file-management system, 
enabling the user to catalog a collection of graphical data for later recall. The computer response 
was still slow and unresponsive, but the user was not required to be in constant attendance, since 
there was no longer any interaction. The pictures were generated individually and stored on the 
disk file of the 1800 with no pause between frames. At the conclusion of the run, the user could 
return to the terminal and redisplay any or all of the frames on a selective basis. This retrieval 
system is rapid enough to satisfy the user response requirements. This concept has now been carried 
one step further by attaching a local disk file to the display device (IMLAC). With this facility, the 
pictures may be retrieved even if the support computer is temporarily unavailable. A mechanical 
plotter driven by the IMLAC computer enables pen and ink copies to be made at the user’s site. 
This mode of operation, sometimes referred to as “fast-batch,” has been the principal technique for 
ACSYNT graphics up to the present time (fig. 1 5). 


ACSYNT SUPPORT COMPUTER 


The system as described in the previous section represents a good adaptation to the computing 
environment as it existed when the system design was made. However, during the implementation 
of the system, the facilities available underwent a significant change, and the graphics support has 
been redesigned to adapt. 

The previously described system was based on the assumption that the ACSYNT program 
would be executed on the time-shared system (the IBM 360/67). Because this computer was so 
overloaded, time was made available on a Control Data 7600 located at the Lawrence Berkeley 
Laboratory (LBL) and accessed through a remote job entry (RJE) station at Ames. This meant that 
two versions of ACSYNT were kept in operation-one on the 360 with graphics and one on the 
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7600 without graphics. As seen by the user, the performance of the 7600 was so superior in terms 
of cost and turn-around time that all the jobs were run there. The advantage of having graphical 
output could not overcome the disadvantages of long running time and slow turn-around. 

Early in 1975, the LBL arrangement was replaced by the installation of a similar machine at 
Ames. Since it was apparent that this machine would be the site for execution of ACSYNT for 
several years to come, a design study was initiated to find a way to make the graphical output 
available. 

The Cyber 76 machine installed at Ames does not support interactive terminals in that way 
that the 360 does, but it does support a network of RJE stations at various points about the 
laboratory. The most direct approach to obtaining graphical output at the remote site is to have a 
combined graphics/RJE station. Such a station has been installed and is now being brought into 
operation. The station is based on a minicomputer (PDP-1 1/40) and utilizes a high-quality, three- 
dimensional CRT display (Evans & Sutherland Picture System), local disk and tape storage, and an 
electrostatic printer-plotter (fig. 16). An interface to the previously described IMLAC PDS-1 is also 
available. The three-dimensional features of the Evans & Sutherland display enable the aircraft to be 
viewed from any angle, thereby relieving the host machine of the burden of computing a large 
number of views. 

In the operational scenario for this station, the user prepares an input case for ACSYNT on the 
local minicomputer and enters this into the input Job queue on the host machine (7600) (fig. 17). 
The job is executed by the host; the user observes this fact via the usual remote station inquiry/ 
response protocol. The file of computed results is transmitted to the minicomputer disk. The 
pictures are composed and displayed as many times as necessary for insight and understanding to be 
conveyed to the user while the host machine has proceeded to other computational tasks. After 
detailed study of these results, the user may wish to change his input data and resubmit the case 
from the minicomputer station. The process is repeated over and over until the desired study result 
is obtained. The number of complete turn-arounds accomplished each day depends on the job time 
and priority. By splitting the workload-giving the host only those functions requiring a large-scale 
computer and giving the local minicomputer the remainder-the total study time can be minimized. 


CONCLUSIONS 


The results of the aircraft design process are best given in graphical, pictorial, and tabular form. 
It is an essential requirement that as many of the plots as possible be computer generated. Early 
attempts at the NASA Ames Research Center were based on interactive generation of the plots on a 
time-sharing system. This general approach has proven infeasible, and two alternative approaches 
based on rapid retrieval of pictures from batch runs have been implemented. These systems, which 
are based on distributed computing, are more practical than the former approach until adequate 
interactive facilities can be made available. 
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Figure 3.— Perspective view of AWACS escort. 



Figure 4.— Perspective view of ATLAS airplane. 
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Figure 1 1 Throttled engine characteristics. 
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Figure 1 2.— Aircraft mass distribution. 
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Figure 13.- ACSYNT graphics file management. 
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IBM 360/67 IMLAC PDS-1 

Figure 14.— Original concept of ACSYNT graphics. 



DISPLAY COMPUTER 
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Figure 15.— “Fast-batch” graphics. 
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Figure 16.— ACSYNT support processor. 
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Figure 1 7.— Operational scenario. 
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